J9 hits a pre-existing, unrelated glibc heap-corruption bug that MALLOC_CHECK_ now surfaces as a hard abort; gate it off until that's investigated separately.

isRawPointer() only checked RAW_POINTER_MASK, letting raw J9 ASGCT BCIs
that never went through encode() misroute into JVMSupport::resolve(),
which asserts false for non-HotSpot VMs. Require ENCODED_MASK too.

It was registered in Main.java's antagonist factory but never added to
either config's ANTAGONISTS string, so it silently never ran in CI.

Include ACTIVE_PHASE_MILLIS in STALE_RACER_SLEEP_MILLIS so racers wake as
the next active phase begins instead of ~3s early. Bound stopGracefully's
total wait to the caller's timeout via a shared deadline instead of giving
each join/tryAcquire the full budget independently.

Without a RUNTIME arg, chaos_check.sh silently proceeds with an empty
value, which becomes --duration s in the chaos harness invocation and
fails 15+ seconds later — after the JDK/agent/jar setup — with a
NumberFormatException buried in the harness output, reported generically
as "FAIL:Chaos harness crashed (RC=1)". Check for a missing RUNTIME right
after arg parsing and fail immediately with a clear usage message.

Environment: Datadog workspace

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

watchFreedContextMemory() deliberately read freed ProfiledThread memory
to detect stale writes, tripping ASan/TSan on every free (e.g. in
forced_unwind_ut) unrelated to the actual race under investigation.

…profiler-only run

…IER mode

Without --add-exports java.base/jdk.internal.misc=ALL-UNNAMED, OtelContextStorage
silently falls back to ContextStorageMode.THREAD, which vthread-context-cascade
was built to catch: virtual-thread context buffers pinned to a since-freed
carrier's ProfiledThread, corrupting the heap.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

profiler+tracer chaos runs OOMKilled on aarch64 (exit 137) with gmalloc/jemalloc
but not tcmalloc, which already had aggressive-decommit tuning for the same
thread-churn RSS-inflation issue. Apply the equivalent tuning to the other two
allocators.

Measured on matching-arch hosts: this workload floats at ~2.6-2.75GB RSS
regardless of MALLOC_CHECK_/allocator tuning, ruling that out as the OOM
cause. Trim -Xmx to 1536m on aarch64 for real headroom, and log the
container's actual cgroup memory limit so future OOMs are diagnosable
from the job log directly.

…ce-chain JFR roundtrip test

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…shared test-JVM heap

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…owth

_table_size was volatile but updated via __sync_bool_compare_and_swap,
which has no synchronizes-with edge under the C++ memory model - switch
to std::atomic<int> with relaxed ops. Also clamp the reference-chain
tests' per-round allocation growth at round 10 (trend-eligibility point)
so retry rounds stop adding unbounded garbage, which was causing OOME in
CI's shared test-JVM heap.

The glibc-aarch64 job never installed gtest/gmock, unlike amd64 and
musl jobs, so all native gtests silently skipped there. This surfaced
as a hard failure once ReferenceChainJfrParserTest started depending
on the roundtrip gtest actually producing its JFR file.

…from reference-chain BFS reconstruction

Both mechanisms are probabilistic and hard to reliably co-occur in one JVM run; new JNI test seams (guarded by #ifdef DEBUG) let JUnit tests seed population history and tag a known live object directly, verifying each end-to-end in isolation.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…racking

Addresses review findings from PR #644 (reference chains for surviving
live-heap samples): FrontierTable's shared-lock mutation race, a
single-byte JFR event size prefix that silently truncates chains longer
than 255 bytes, blocking sample-lock retries in writeReferenceChain()
now bounded by a shared per-batch deadline with a drop counter,
unvalidated referencechains sub-option values, a startThread()/
pthread_kill() race publishing _running before the thread handle is
initialized, a null-JNIEnv leak in threadLoop(), releaseSearchTags()
now surfacing GetObjectsWithTags() failures so restartSearch() never
resets tag state prematurely, resolveLoadedClasses() skipping its
per-class scan only when the loaded-class count is unchanged (not just
non-decreasing), a spurious COMPLETED state after a failed first-pass
FollowReferences call, and removal of a leftover debug helper in
ExternalProcessReferenceChainTest. Adds regression test coverage for
release-failure and negative-value option paths.

Verified via the full ddprof-lib gtestDebug suite (149/149 tasks,
57/57 referenceChains_ut tests).

Environment: Datadog workspace

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

resetSearchStateForTest() and klassPopulationResetForTest() now stop the
BFS thread / take _table_lock respectively before mutating state the
thread otherwise owns exclusively. Also reset LivenessTracker's own
population history before shouldReconstructReferrerChainThroughUnboundedCacheLeak()
so a stale candidate from the prior test can't outrank CachedPayload, and
align its per-round growth rate with the sibling test's.

StringDictionary::clearAll() (on profiler restart) wipes dict ids but
JVMTI class tags survive, so ReferenceChainTracker::_class_tags held
ids into a namespace that no longer existed. Add a generation counter
to StringDictionary and have resolveLoadedClasses() detect a mismatch
and force re-resolution, reusing existing JVMTI tags instead of always
minting new ones. Also adds a firstpassbudget override for the
root-seeded first BFS pass.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…samples

cleanup_table()'s per-klass population accounting was gated on !forced,
skipping it entirely whenever track()'s table-overflow branch triggered a
forced sweep. Gate on a new is_epoch_owner check instead (true once per
genuinely new GC epoch, forced or not), so a forced sweep still folds a
sample using an already-cached klass id. resolveKlassId() (a real
Class.getName() Java upcall) still only runs on the organic path - that
part was a legitimate hot-path cost concern, just misdescribed as a JVMTI
safety requirement.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

resetSearchStateForTest() only reset the frontier table's occupancy,
not its capacity, so an earlier test's smaller framecap= permanently
capped the singleton for every later test in the same JVM.

…ceChainTestSeamsTest

An earlier test can leave the shared FrontierTable full/tiny
(shouldReportAbandonedSearchOnTinyFrontierCap deliberately caps it at 1);
without resetting first, tagAsReferenceChainRoot0()'s insert() fails
deterministically.

Profiler::dump() discarded _jfr.dump()'s Error entirely, and
OS::copyFile()'s sendfile() loop broke silently on short/failed
copies - both are debug-only visibility gaps that would otherwise
leave a lost reference-chain write or truncated chunk copy
unexplained in CI logs.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Same debug-only seeded-representative short-circuit already used by
ReferenceChainTrackingTest, ported to the external-process scenario:
propagates ddprof_test.config to the child JVM so it can bypass
LivenessTracker's probabilistic slope detection instead of depending
on it to notice CachedPayload within the fixed round/timeout budget.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

…647)

…ubuntu.com

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>